1. Field of the Invention
The present invention relates to a multicast data communication method, which multicasts data to a plurality of clients (receivers) on the existing Internet, supporting only one-to-one communication (unicast), a multicast data communication system, a repeater, a repeating method, and a medium for storing repeating programs.
2. Description of the Related Art
Conventionally, IP multicast is a method for realizing multicast communication for multicasting data to a plurality of clients on the Internet, by using predetermined multicast IP addresses. In this method, when a server (transmitter) transmits data with a multicast IP address as the destination, a multicast router (repeater) installed on the Internet copies the data during delivery when necessary, and delivers identical data to all the clients.
Normally, the data delivery path from the server to the plurality of clients is a tree having the server as its root and the clients as its leaves. This is termed a multicast tree. In IP multicast, the multicast tree is constructed from protocols such as DVMRP (Distance-Vector Multicast Routing Protocol) of RFC1075, MOSPF (Multicast Open Shortest Path First) of RFC1584, PIM-SM (Protocol Independent Multicast-Sparse Mode) of RFC2362, and a protocol IGMP (Internet Group Management Protocol) of RFC1112 manages the joining and leaving of the clients to/from the tree.
To realize the IP multicast mentioned above, all routers must be compatible with IP multicast. However, the reality is that many routers are not compatible with IP multicast, making it very difficult to implement with all routers. IP multicast has another disadvantage that it is not possible to pass a multicast packet through a network which is not compatible with multicast. Moreover, to realize IP multicast, the client must expand its function at the operating system level, and consequently it is not easy for individual clients to make themselves compatible with IP multicast.
The abovementioned protocols have a drawback of no scalability. In DVMRP, even when no client exists, the multicast tree is constructed to the router nearest the client and data is delivered. In MOSPF, each node must keep topology information relating to the whole of the massive multicast tree. In PIM-SM, a client joining the multicast tree must access a specific node termed a “rendezvous points”.
Furthermore, since the above protocols must guarantee that the multicast IP address is global and unique, the cost of managing the addresses to identify the multicast tree is high. In addition, the above protocols allow hosts who are not participating in the multicast tree to become servers, enabling an attack from a malicious host to send unwanted traffic to participants in the multicast tree.
Japanese Unexamined Patent Application, First Publication No. Hei 10-63598 discloses a multicast data communication method using only unicast, and not using IP multicast. According to this method, a multicast server (node or repeater) who has received a request from a client to start receiving, stores the address of the client, and thereafter delivers multicast data to that client until a request to end receiving is received from that client.
However, this method has a problem that the delivery of multicast data to the client does not stop when the request to end receiving from the client has been lost during transmission, or when the client has hung up. A further drawback is that, once the delivery path has been decided by the request to start receiving, the delivery path to the client does not change, even when the nearest node to the client has changed due to a change in the route information of the router.
FIG. 71 shows one example of a network constitution for multicast communication, and shows four clients 2-1, 2-2, 2-3, and 2-4 connected via a network to one node 1.
Let us imagine that an unillustrated server is connected to the node 1 via the network. The four clients 2-1, 2-2, 2-3, and 2-4 have addresses 10.10.9.8, 10.11.10.9, 10.12.11.10, and 10.13.12.11, and are located on the opposite side of the node 1 to the server.
Now let us suppose that of the four clients 2-1 to 2-4, the three clients 2-1 to 2-3 with the addresses 10.10.9.8, 10.11.10.9, and 10.12.11.10, have transmitted request packets. When the request packets arrive at the node 1, a table for the server is created at the node 1, and the three clients 2-1 to 2-3 are registered in the table.
The table shows that the node 1 should duplicate a delivery packet from the server, and delivery it to the three clients. The clients registered in the table are known as the “children” of the node 1.
FIG. 72 shows an example of the table. The addresses of the children are stored in the table.
When a new table is created, the node 1 itself transmits the request packet. In order to send the request packet to a node near the server, some sort of method is used to determine a routing tree for each multicast identifier. In this way, the request packet eventually arrives at the server.
FIG. 73 shows another example of the constitution of a network where multicast communication is carried out, and shows three nodes 11-1, 11-2, and 11-3 connected to seven clients 12-1, 12-2, 12-3, 12-4, 12-5, 12-6, and 12-7 and one server 13 via the network.
Next, the process of forming a multicast tree will be explained.
Let us suppose that the client 12-1 sends a request packet, as shown in FIG. 74. At this time, a table showing that the client 12-1 is a child of the node 11-1 is created at the node 11-1, and, as shown in FIG. 75, the node 11-1 transmits the request packet.
When the request packet arrives at the node 11-2, the node 11-2 similarly creates a table, and registers the node 11-1. Then, the node 11-2 transmits the request packet. The arrival of the request packet at the server 13 informs the server 13 that the data should be sent to the node 11-2, and the server 13 starts to transmit the delivery packet.
Thereafter, let us suppose that the client 12-2 transmits a request packet, as shown in FIG. 76. When this request packet arrives at the node 11-1, the client 12-2 is registered in the existing table. When the client 12-4 sends a request packet, as shown in FIGS. 77 and 78, the node 11-3 registers the client 12-4, and the node 11-2 registers the node 11-3. FIG. 79 shows the state when the clients 12-5 and 12-6 have also joined the multicast.
Thus a tree-shaped delivery path is constructed with the server as the root and the clients as the leaves. This type of tree-shaped delivery path is created for each server. When the tree is identified by a code termed a tree ID (multicast identifier), as shown in FIG. 72, a table for each tree ID is created at the node.
At each node, the delivery packet transmitted from the server is duplicated when necessary, and then sent to the children registered in the table. For this reason, even when the path from the clients to the server is different from the path from the server to the clients, the delivery packets always pass through nodes where tables have already been created.
When a client wishes to stop receiving the delivery packets, the client transmits a leave packet; when the leave packet arrives at the node, the node simply deletes the client who sent the leave packet from the table. Then, when the children registered in the table have disappeared, the node outputs a leave packet. As in the case of the request packet, the leave packet is transmitted by some sort of method to the node nearest the server. As disclosed in Japanese Unexamined Patent Application, First Publication No. Hei 10-63598, the nodes need only repeat the same process.
However, the communication method described above has a drawback that, when a client has hung up or forcibly terminated communication without transmitting a leave packet, the client remains registered in the table at the node, and the server continues to send delivery packets to this client.
To prevent this, the node is provided with a timer, and sends regular inquiries to the children registered in its table. When a reply packet has been returned from the child, the node concludes that the child is still receiving, and continues to transmit the delivery packets; when no reply arrives, the node terminates transmission.
When a parent node has sent an inquiry to the node, the node sends back a reply packet in the case where the child is registered in the table; when no children are registered in the table, the node either does not send a reply packet or sends a leave packet to the parent node. The tree is maintained in this way so that the delivery packets are only delivered to children who return reply packets.
For example, in the network constitution shown in FIG. 71, the node 1 sends inquiries to the three children (clients) having the addresses 10.10.9.8, 10.11.10.9, and 10.12.11.10, which are registered in the table as shown in FIG. 72. Let us suppose that the children with the addresses 10.10.9.8 and 10.11.10.9 are operating correctly, and have replied by sending reply packets, but the child with address 10.12.11.10 has hung up, and consequently has not sent a reply packet. The node 1 now determines that it is not necessary to deliver the delivery packet to the child with address 10.12.11.10, and, as shown in FIG. 81, deletes that child from the table.
Alternatively, instead of sending the delivery packet and the inquiry packet separately, the delivery packet can be treated as an inquiry packet, and when the client (or the node) receives the delivery packet, they send a reply packet to the server.
However, according to these methods, the client (or the node) must transmit a request packet at the start of receiving in order to be registered in the table of the parent node. In a network where there is the possibility of losing the request packet, the client (or the node) must repeatedly transmit the request packet until it is registered in the table of the parent node. A reply packet is then sent with regard to the delivery packet after the client (or the node) has been registered in the table. That is, there is a problem that a state transition is required from actively transmitting a packet to passively transmitting a packet.
Techniques similar to that in Japanese Unexamined Patent Publication, First Publication No. Hei 10-63598 described above have been disclosed in Hugh W. Holbrook, David R. Cheriton, “IP Multicast Channels: EXPRESS Support for Large-scale Single-source Applications” pp. 65-78, In Proc. of SIGCOMM, 1999, and in Ion Stoica, T. S. Eugene Ng, Hui Zhang, “REUNITE: A Recursive Unicast Approach to Multicast” pp. 1644-1653, in Proc, of INFOCOM2000 (hereinafter termed REUNITE).
The first of these documents proposes a method of IP multicast expansion termed “source-specific multicast” (SSM), wherein a source address and a multicast address are coupled together to identify the multicast tree. The REUNITE document describes a multicast technique in an application layer, where the multicast tree is determined based on the forward-path to the first client who transmits a request. When this client later leaves the multicast tree, the multicast tree is determined based on the forward-path to another client, changing the constitution of the multicast tree.
However, the methods of Japanese Unexamined Patent Publication, First Publication No. Hei 10-63598, SSM, and REUNITE, have security problems such as the following. Any server or client can create a table at any node on the path from server/client to the destination by transmitting a packet having a table-creation function (e.g. the request packet described above) with a random terminal address as the destination. By taking advantage of this, a malicious user can send table-creation packets to a great number of addresses, creating a great number of meaningless tables in the network nodes. As a result, the load of the nodes becomes unnecessarily heavy, reducing their capability.